home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / dev / www_talk.930 / 000182_connolly@pixel.convex.com _Thu Jul 16 06:07:03 1992.msg < prev    next >
Internet Message Format  |  1994-01-24  |  10KB
  1. Return-Path: <connolly@pixel.convex.com>
  2. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  3.     id AA05357; Thu, 16 Jul 92 06:07:03 MET DST
  4. Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
  5.     id AA11230; Thu, 16 Jul 92 06:06:44 +0200
  6. Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
  7.     id AA26267; Wed, 15 Jul 92 23:06:19 -0500
  8. Received: from localhost by pixel.convex.com (5.64/1.28)
  9.     id AA28878; Wed, 15 Jul 92 23:06:17 -0500
  10. Message-Id: <9207160406.AA28878@pixel.convex.com>
  11. To: www-talk@nxoc01.cern.ch
  12. Subject: RE: Minutes of the "UDI" BOF at the 24th IETF
  13. Mime-Version: 1.0
  14. Content-Type: text/x-html
  15. Date: Wed, 15 Jul 92 23:06:17 CDT
  16. From: Dan Connolly <connolly@pixel.convex.com>
  17.  
  18. <!DOCTYPE HTML SYSTEM>
  19. <H1>RE: 
  20. <A HREF=
  21. "http://info.cern.ch/timbl/Public/USTrip1992/IETF-24/UDI_BOF_Minutes.html">
  22. Minutes of the "UDI" BOF at the 24th IETF</A></H1>
  23.  
  24. [The gopher folks are dicussing how to add the "reply"
  25. feature from USENET newsreaders to gopher clients.
  26. I wish www had that feature too. The "followup" feature
  27. is currently beyond the scope of WWW, but...]
  28. <p>
  29.  
  30. [I'm beginning to wish www was a mail user agent and
  31. a gopher client and a news reader and a WAIS client
  32. all in one. Soon...]
  33. <p>
  34.  
  35. [We need a DTD that models the USENET thread model,
  36. with posts, followups, quotes, points, counterpoints,
  37. flames, signatures, etc.<p>
  38.  
  39. Right now, I have to modify a destination document (add an anchor) to
  40. link to an element of that document. We should look at what HyTime and
  41. the TEI use for references to SGML elements without IDs. I saw a
  42. HyTime description that said you could link to non-hyptime documents.
  43. Maybe we could use this to reference passages of news articles etc.  ]
  44.  
  45. <p>
  46.  
  47. <H2>Quote</H2>
  48.  
  49. The information one quoted in a reference to an object could comprise
  50. many things, among which were possible one unique name, (Unique
  51. Resource Number, URN was one acronym), and zero or more addresses
  52. (Uniform Resource Locators or URLs) which gave instructions for
  53. retrieving the object.
  54.  
  55. <h2>Response</H2>
  56.  
  57. Cool! The model for global hypertext that swims around in my mind
  58. includes references which consist of identifiers and addresses. On the
  59. subject of URNs, it sure would be nice to be able to verify that the
  60. data mentioned in the link and the data retrieved from the URL are the
  61. same.
  62. <p>
  63.  
  64. For instance, I could reference an FTP file, and somebody could
  65. write over it. I might look like a fool arguing against old
  66. information. If I give a URN in the link, the browser could warn
  67. that it doesn't match the URN of the retrieved document.
  68.  
  69. <h2>Quote</h2>
  70.  
  71. NOT to be discussed were the differences between names and addresses,
  72. URN schemes (which are not yet well enough defined), the full set of
  73. information to be given in a reference, or IPv7.
  74. <p>
  75.  
  76. <h2>response</h2>
  77.  
  78. I think internet message ID's make great URN's.
  79.  
  80. <h2>quote</h2>
  81.  
  82. To be discussed were the overall string syntax, including allowed
  83. characters and escaping systems for unallowed characters, the order of
  84. components (little/big-endian), punctuation characters, the particular
  85. prefix to be used to identify each namespace.
  86.  
  87. <h2>Response</h2>
  88.  
  89. Cool. This makes URLs orthogonal to MIME external body part
  90. references. I believe where they are not orthogonal, they should
  91. coincide.
  92.  
  93. <h2>quote</h2>
  94.  
  95. It was pointed out that for WAIS one could imagine a separate name
  96. space for databases and for documents. If this was taken futher, a
  97. separate prefix would be used for each type of object. It was on
  98. balance agreed that this could go too far. One prefix should be used
  99. per protocol, but it should be made clear how to determine the type of
  100. an object from the URL.
  101.  
  102. <h2>response</h2>
  103.  
  104. Note how nicely all this coincides with MIME external body part
  105. constructs. Such a body part looks like, for example:<XMP>
  106. Content-Type: message/external-body;
  107.     access-type=x-http;
  108.     host="info.cern.ch";
  109.     path="/timbl/Public/USTrip1992/IETF-24/UDI_BOF_Minutes.html"
  110.  
  111. Content-Description: Minutes of the "UDI" BOF at the 24th IETF
  112. Content-Type: text/x-html
  113.  
  114. </XMP>
  115. <p>
  116.  
  117. In general, a MIME external body part looks like:<XMP>
  118. Content-Type: message/external-body;
  119.     access-type=_type_; /* local-file, anon-ftp, afs, or x-token */
  120.     _other_parameters_ /* path, host, name, database, etc. */
  121.  
  122. Content-ID: _message-id_ /* of external body part */
  123. Content-Description: here's what you'll get!
  124. Content-Type: _base_/_subtype_ /* type of data in external body part */
  125.  
  126. ghost body goes here. This is _not_ the contents of the body part,
  127. but it is available to the user agent that's fetching the data.
  128. It could be used, for example, for the seed-words of a WAIS reference.
  129. </XMP>
  130.  
  131. It looks like a URL is a condensed version of the MIME external body
  132. part headers. The URL scheme:____blah____ syntax maps nicely to
  133. MIME access-type=scheme; ___parameters for blah___.
  134.  
  135. <h2>quote</h2>
  136.  
  137. The class of object you get back should be predictable (--C Lynch).
  138. W3 has a real problem with that, since everything is a "document" and
  139. handled in a similar way.
  140.  
  141. <h2>response</h2>
  142.  
  143. I don't agree that "everything is a 'document'" to the W3 browser. The
  144. browser knows it's getting gopher directory info from gopher UDI's,
  145. for example. I think the type of data it returns can and should be
  146. classified by the MIME typing system, even if it does so implicitly.
  147.  
  148. <h2>quote</h2>
  149.  
  150. Should one use punctuation, or attribute-value pairs? Attribute value
  151. pairs get mispelt. (note x.400 vs.internet addresses)<p>
  152.    
  153. It was decided to use a short string with punctuation rather than an
  154. attribute-value pair system.<p>
  155.  
  156. <h2>response</h2>
  157. I have doubts about the ability to be able to encode all this
  158. information (scheme, host, path/selector-string, type, etc) in
  159. something akin to a phone number that can be written on one line of
  160. text with no spaces. I think that within each scheme, folks develop
  161. printable syntaxes for making references (ange-ftp, WAIS source files,
  162. etc.).<p>
  163.  
  164. But the scope of URLs is so vast that I wonder if folks will form
  165. habits over this whole domain.<p>
  166.  
  167. I advocate that the W3 format include, at least experimentally, an
  168. SGML element for each access type, with the URL pre-parsed into
  169. attribute-value pairs. The anchor element could become more complex,
  170. including sub-elements for URLs and URNs. Data type information could
  171. be included somewhere.<p>
  172.  
  173. The HTTP access type doesn't require type information: format
  174. negociation is part of the HTTP protocol. But WAIS and Gopher
  175. references require these types, and it would be nice for FTP
  176. references (at least to choose between image and text transfers.)<p>
  177.  
  178. I'll think it over and work on a DTD that uses these pre-parsed URLs.
  179.  
  180. How do these examples look?
  181. <XMP>
  182. <A HREF=
  183. "http://info.cern.ch/timbl/Public/USTrip1992/IETF-24/UDI_BOF_Minutes.html">
  184. Minutes of the "UDI" BOF at the 24th IETF< /A>
  185.  
  186. becomes
  187.  
  188. <A><HTTP host="info.cern.ch"
  189.  path="/timbl/Public/USTrip1992/IETF-24/UDI_BOF_Minutes.html">
  190. Minutes of the "UDI" BOF at the 24th IETF< /A>
  191.  
  192. and
  193.  
  194. <A NAME=gopher
  195. HREF=gopher://gopher.micro.umn.edu:70/11/Other%20Gopher%20and%20Information%20Servers>
  196. list of sites< /A>
  197.  
  198. becomes
  199.  
  200. <A NAME=gopher>
  201. <Gopher type="text/x-gopher-1"
  202.         host="gopher.micro.umn.edu" port=70
  203.         selector="1/Other Gopher And Information Servers">
  204. list of sites< /A>
  205. </XMP>
  206.  
  207. The idea here is that we've got a parser already: the SGML parser.
  208. Why not use it to parse the various bits of data we need to reference
  209. data located elsewhere?
  210.  
  211. <h2>quote</h2>
  212.  
  213. A separate issue of whether human or only machine readable.
  214. Previously, included issue of printable.  This is needed because don't
  215. have names now.  Question arose of whether once these addresses exist
  216. will be replaceable with names - will be presented as new
  217. functionality, not replacing existing systems. Agreement on some way
  218. of specifying class of objects.
  219.  
  220. <h2>response</h2>
  221.  
  222. This reminds me of <A HREF="AUGMENT:132082,#11l"> Knowledge-Domain
  223. Interoperability & an Open Hyperdocument System
  224. </A>
  225.  by Douglas C. Engelbart in which he gives requirements for his
  226. system.
  227. <p>
  228.  
  229. One of them is:
  230.  
  231. <H4>Hard-Copy Print Options to Show Addresses of Objects and Address
  232. Specification of Links</H4>
  233.  
  234. <h5> ... so that, besides online workers being
  235. able to follow a link-citation path (manually, or via an automatic
  236. link jump), people working with associated hard copy can read and
  237. iterpret the link-citation, and follow the indicated path to the cited
  238. object in the designated hard-copy document.<p>
  239. <p>
  240.  
  241. Also, suppose that a hard-copy worker wants to have a like to a given
  242. object established in the online file. By visual inspection of the
  243. hard copy, he should be able to determine a valid address path to that
  244. object and for instance hand-write an appropriate link specification
  245. for later online entry, or dicate it over a phone to a colleague.</H5>
  246.  
  247. That document deserves a thorough reading by the whole
  248. comp.infosystems.* community.
  249.  
  250. <h2>quote</h2>
  251.  
  252. IT WAS AGREED that the context, or namespace, prefix be the first
  253. (leftmost) part of the URL, and be separated from the rest of the URL
  254. by a colon.
  255.  
  256. <h2>response</h2>
  257.  
  258. Has anybody given any thought to a syntax with implied schemes so that
  259. the ange-ftp style URLs and internet message ID URNs that are out
  260. there can be used?<p>
  261.  
  262. If we reserved a character to _start_ UDIs, then we could try to infer
  263. the scheme of strings that don't start with that char. Let's take
  264. () for URL schemes and [] for URN schemes.
  265.  
  266. <XMP>
  267. For example: host:path == (ANON-FTP)host:path
  268.              path@host == (ANON-FTP)host:path
  269.              <message-id@host> == [rfc-822]<message-id@host>
  270. </XMP>
  271.  
  272. Well, I suppose this type of thing is really akin to the W3 local
  273. UDI scheme: it's application specific.<p>
  274.  
  275. <h6>Postscript: This document was prepared using emacs with the help
  276. of Eric Naggum's
  277. <A HREF="file://ftp.ifi.uio.no/pub/SGML/elisp/sgml-mode.el">
  278. sgml-mode</A>, and verified by sgmls-0.8 with the DTD in <A
  279. HREF="message-id:<9207160335.AA24812@pixel.convex.com>">html.dtd
  280. </a>
  281. . This is proof of concept that the W3 browser handles conforming
  282. SGML. I also wrote
  283. <a
  284. href="message-id:<9207160349.AA25229@pixel.convex.com>"> a short perl
  285. script</a> that will bring many existing HTML files into conformance.
  286.  
  287. </h6>